Businesses typically employ enterprise-wide database engines in order to allow employees, customers, and other such users, to access data stored in one or more data files maintained thereby. Users typically access a database engine over a computer network in which a user's computing terminal may communicate with one or more servers maintaining the database engine. Examples of such database engines include those supporting Structured Query Language (SQL) formats, Open-Database Connectivity (ODBC) and Javascript Database Connectivity (JDBC) protocols produced by MICROSOFT, ORACLE, SYBASE, SUN MICROSYSTEMS and the like.
Businesses employing such database engines typically find that it is difficult to convert to or incorporate an alternate database engine that is produced by another database manufacturer or that employs a differing data format. This problem, known as entrenchment, arises due to costs that arise from conversion between competing database products. These costs are due largely to the nature of existing computer software, in that differing data standards, command structures, and file formats are typically used by competing database manufacturers. For example, conversion of any data stored by an established database engine to a format supported by the new database engine may be labor-intensive, and therefore, expensive. In addition, new data commands corresponding to the new database engine must be learned by users in order to interact efficiently with them. The process of learning new commands temporarily reduces the user's efficiency, thereby impacting his or her efficiency. Businesses then may determine that the costs associated with conversion would prevent them from selecting a new database engine, if when it would provide new or more desirable functionality.
A business or other entity is thus largely wedded to a particular established database system once it has been selected and implemented. Over time, entrenchment may result in additional unwanted costs. For example, a database manufacturer may require its customers to purchase software upgrades periodically, in order to maintain service contracts and the like for the established database engine, even when such upgrades do not provide any additional functionality that is specifically beneficial to the business.
In another example, a business may wish to expand database services to users by providing additional database servers on the computer network, particularly where large amounts of data are maintained or large numbers of users are provided with access. In such a case, the business would be forced to purchase another license for the established database engine to run on a new server, even when less costly database engines may be available.
Various solutions to the entrenchment problem have been attempted. A first example involves certain database engines that periodically copy or replicate data stored by an established database engine and provide it to further users. However, this solution is not ideal in the case of temporally-sensitive data that changes on a continuing basis, such as a historical stock price data. There is inherently some delay associated between conversion of the data between the established and the new database engines. Also, there is a delay associated with data transfer between the two database engines. This may result in inaccurate result sets being generated and returned to users accessing such database engines.
A second example is a class of software products known as middleware applications, such as ODBC produced by MICROSOFT, and JDBC by SUN MICROSYSTEMS. In such applications, the network connectivity layers of the middleware and the established database system are still tied together. Thus, database commands submitted to the middleware application must be processed by a command software layer of the established database system. In a case where the new database engine is implemented to relieve some of the processing performed by the established database engine, system usage resources and other costs, including financial costs, associated with the established database engine are still negatively-impacted.
A final example is a class of software products commonly known as database gateway products. These products provide a command gateway between competing database engines of differing data formats, allowing users to submit one command to interact with two or more such separate, supported, database engines. Examples of such gateway products include TRANSPARENT GATEWAY by ORACLE, MICROKERNEL by PERVASIVE, OMNISQL by SYBASE, STARNET and STARGATE produced by POWERHOUSE and DB INTEGRATOR by DIGITAL EQUIPMENT CORPORATION. However, these gateway products generally require continuous maintenance and customization. For example, data mapping in a metadata mapping layer must be continuously changed with every change to the separate supported database engines. Furthermore, the command layer of each separate database engine is accessed by such gateway products in order to process database commands, thus impacting system resources of each server that maintains a database engine. Again, the desired purpose of having a separate database engine may be to relieve some processing from an established database engine. In such a case, this final example is not an optimal solution since system resources of both database engines are impacted.
Accordingly, there is a need for a method and apparatus for implementing and using an alternate database engine with an existing database engine that addresses certain problems of existing technologies.